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ABSTRACT 

Over the last decade, consumer technology has vastly improved its performances, become more 
affordable and reduced its size. Modern day smartphones offer capabilities that enable us to figure 
out where we are, which way we are pointing, observe the world around us, and store and transmit 
this information to wherever we want. These capabilities are remarkably similar to those required 
for multi-million dollar satellites. The PhoneSat project at NASA Ames Research Center is building 
a series of CubeSat-size spacecrafts using an off-the-shelf smartphone as its on-board computer 
with the goal of showing just how simple and cheap space can be. 

Since the PhoneSat project started, different suborbital and orbital flight activities have proven the 
viability of this revolutionary approach. In early 2013, the PhoneSat project launched the first triage 
of PhoneSats into LEO. In the five day orbital life time, the nano-satellites flew the first functioning 
smartphone-based satellites (using the Nexus One and Nexus S phones), the cheapest satellite (a 
total parts cost below $3,500) and one of the fastest on-board processors (CPU speed of 1GHz). In 
this paper, an overview of the PhoneSat project as well as a summary of the in-flight experimental 
results is presented. 

1 CONSUMER TECHNOLOGY FOR SPACE APPLICATIONS: THE 

SMARTPHONE 

Start with the smartphone, a device that enables command and data handling, position and attitude 
determination, observation, and wireless communication - a set of subsystems remarkably similar 
to a conventional multi-million dollar satellite at a fraction the cost. From here, the PhoneSat 
Project has expanded to explore leveraging the investment of any consumer industry to build space 
systems. The root objectives of the project are to reduce cost whilst increasing capability. 

The method of repurposing consumer technology has brought along different mindsets from which 
to look at space. For PhoneSat, a new approach to space development has been adopted - release 
early, release often. This agile space development approach is far more suited to low cost, un- 
manned space applications than the traditional systems engineering methods. 

The PhoneSat project consists of the development of a series of nano-satellites that use an off-the- 
shelf smartphone as their on-board computer. By doing so, PhoneSat takes advantage of the high 
computational capability, large memory as well as ultra-tiny sensors such as high-resolution 
cameras and navigation devices that smartphones offer. In addition, having the option of using the 
Open Source Android Operating System provides a large variety of existing libraries, as well as a 
modular software approach which enables fast iteration time-frames and an ease of crowd sourced 
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applications. Space has shifted paradigm from a hardware problem to a software problem. 

The full potential of removing cost as a barrier to entry in space is still being realized and explored 
by the global community. Two predominant applications being pursued by companies around the 
Silicon Valley Bay Area are Earth observation at unprecedented update rates and space-based 
educational platforms. For science, low cost platforms enable a larger number of experiments to be 
tested, in addition to experiments previously not possible - expanding our knowledge base. 

To date, the PhoneSat Project has flown four satellites demonstrating the feasibility and economic 
advantage of supplementing and augmenting space industry technologies with consumer 
technologies. The focus of this report is around the PhoneSat project and the Antares flight, on 
which two PhoneSat 1.0’s and a beta version of PhoneSat 2.0 were manifested. An overview of the 
project goals will be presented first, followed by the architecture of each satellite version and the 
flight concept of operations. Next, the flight data from the Antares launch will be detailed. Finally, 
future objectives of the project will be presented. 


2 THE PHONESAT PROJECT 

2.1 Long term goal 

The PhoneSat project aims to democratize space by making it accessible to more people. The 
PhoneSat approach to lowering the cost of access to space consist of using off-the-shelf consumer 
technology, building and testing a spacecraft in a rapid way and validating the design mainly 
through testing. PhoneSat’ s role in the space industry consists of exploring ways to do things in a 
non-traditional manner that enables new breakthroughs by providing a platform in space for 
experimentation and testing. 

2.2 Origin and evolution 

The PhoneSat project has been developed at NASA Ames Research Center since its inception in 
2009 after the summer session of ISU (International Space University). The PhoneSat project 
believes in the effectiveness and quick response of small teams and as such, the team has always 
been composed of about half a dozen students and young engineers. 

From the very beginning, the project has adopted an iterative approach for the development of the 
spacecraft. The idea is to frequently release a new iteration of the design that improves the current 
work in order to quickly arrive at a functioning unit - an approach known as “release early, release 
often” that aligns with the local culture in the Silicon Valley. 

From a very early stage, the project realized the potential of smartphones as the main computational 
core for satellites. Given the level of performances and integration smartphones offer, the PhoneSat 
team conducted some additional testing on the ground in order to validate their adaptability for 
space applications. After the success of this preliminary testing, the project decided to develop a 
spacecraft around the smartphone. The first version of the satellite was called PhoneSat 1.0 and 
took the shape of the standard 1U size CubeSat with the main goal of determining whether or not a 
smartphone could survive in a space environment. Upon completing PhoneSat 1.0, the team 
naturally moved to the design of PhoneSat 2.0 with the objective of developing a complete satellite 
bus. In April 2013, the first three PhoneSat satellites were sent to space and successfully 
accomplishing their mission of staying alive. Figure 1 shows a project time line of the events that 
have taken place in the PhoneSat project. 
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Figure 1. PhoneSat project timeline 


3 PRELIMINARY TESTING 

In order to validate the survivability of the smartphone in a space environment, a set of tests were 
conducted using a HTC Nexus One phone. The first test exposed the phone to a vacuum level of 
2E-6 Torr and thermal extremes of -35C and +60C. Under these conditions, no anomalies in the 
performances of the smartphone were observed. Along with the smartphone, an Arduino board was 
tested and showed no evidence of deterioration. 

As a next step in the testing process, a smartphone was flown as a payload in a sounding rocket that 
reached 10km altitude. The payload was also equipped with an Inertial Measurement Unit (IMU). 
During the flight, accelerometer and magnetometer data from the phone and IMU were collected 
and stored in the phone’s SD-card. Other than the accelerometer saturating at about 2G, the test was 
successful since the smartphone was proven to survive launch environment conditions. 

Finally, the smartphone passed vibration and shock tests according to GEVS standards. 


4 PHONESAT 1.0 
4.1 Description 

Based on the success of the preliminary testing, the PhoneSat team started the design of the first 
spacecraft of the PhoneSat family. PhoneSat 1.0’s goal was to prove that a smartphone can actually 
work in space. The design was kept as simple as possible. PhoneSat 1 .0 consisted of a Nexus One 
smartphone that was used as a main flight computer, Li-Ion batteries to increase the operational life 
time of the satellite, an external beacon radio to downlink data from the spacecraft to a ground 
station and a small watchdog to monitor the health of the smartphone and reboot it if any anomaly 
in its performance was observed. Figure 2 shows a photo of PhoneSat 1.0 with some batteries 
removed so the smartphone can be seen from the outside of the spacecraft. The total cost in parts of 
PhoneSat 1.0 is $3,500 and it has probably the fastest processor (CPU of 1GHz) that has ever been 
to space. 
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Figure 2: PhoneSat 1.0 


4.2 Mission objectives 

Demonstrate that a phone can 1) function in space, and 2) can provide a useful computing platform 
in space, by performing one highly complex computing task (advanced image processing) and 
radioing evidence to the ground. 

4.3 Hardware architecture 
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Figure 3: PhoneSat 1.0 hardware architecture 

Figure 3 shows an overview of the hardware architecture of PhoneSat 1.0. The Nexus One phone is 
embedded in the satellite with its battery removed. In place of the battery is a set of 12 Li-Ion 
batteries mounted in a 3D printed battery holder and connected in parallel to provide power to the 
spacecraft for about 10 days of operations. The phone interfaces to the Atmel ATmega 328 that runs 
Arduino software (used as a the watchdog) and the StenSat beacon radio via the phone USB 
connector converted to a serial port. The watchdog is in charge of making sure that the phone 
functions properly and reboots it if misbehaviour is detected. 

PhoneSat uses a StenSat beacon radio, a commercial-off-the-shelf radio in the amateur band, to 
downlink data to the ground. The StenSat beacon transmits packets of data at 1200bps AFSK at an 
RF output power of 1W. PhoneSat 1.0 uses this radio at a frequency of 437.425MHz with a piece 
of tape measure trimmed at the right length as an antenna. 
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PhoneSat 1.0 collects data from the accelerometer and magnetometer sensors built into the phone 
and from two additional temperature sensors located in two different locations in the spacecraft. 
This data is stored in the phone’s memory. The phone camera is also used to take pictures of its 
surroundings. Figure 3 shows a diagram of the PhoneSat 1.0 hardware architecture. 


4.4 Software architecture 


The software of PhoneSat 1.0 is built on top of the Android 2.2 framework. The app developed 
consists of a few activities and modules that are interconnected as shown in Figure 4. 
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Figure 4: PhoneSat 1.0 software architecture 

The package phonesat. service is in charge of handling the Android execution flow of the app. It has 
two classes: the autostart receiver that is responsible for starting the app and the command receiver 
that is in charge of calling the phonesat. executive. Phonesat. executive contains the command 
module service that acts as a scheduler. 

There are four activities that can be run: (1) the camera activity takes 1 picture every time it’s 
called, (2) the sensor data service collects sensor data from the phone and the external sensors, (3) 
the image analyzer is in charge of selecting the best image among the pictures taken according to a 
pre-defined criteria and (4) the image processor is responsible for analyzing and decomposing into 
tiles the picture selected. 

At the phonesat. hardware level, the 10 service contains all of the hardware drivers. The 
phonesat.packet module is responsible for packetizing both the sensor data and the images so they 
can be sent through the beacon radio. 

The smartphone chooses the best picture over the 100 selected. The best picture in PhoneSat 1.0 is 
defined as the one that has a higher edginess, which means that their pixels are more different from 
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the contiguous pixels within the same picture. Once the best picture has been selected, the software 
decomposes it into tiles of three different resolutions (background, medium and high). Every tile is 
contained in an image packet. For each resolution, the number of tiles in which the picture is 
divided is shown below. 

• Background: 1 packet 

• Medium resolution: 64 packets 

• High resolution: 256 packets 

The probability of sending any of this packets depends on the day of the mission (given priority to 
the low resolution packets during the first days and to the higher resolution during the rest of the 
mission) and on the relevance of information on the picture 

4.5 Concept of operations 

Initialization 

Immediately after the spacecraft has been ejected from the launch vehicle, the watchdog powers on. 
The smartphone is turned on by the watchdog 45 minutes after deployment. 

Phase 1 

After the initialization phase, the phone is in phase 1 in which it performs a health check. During 
this phase, each sensor and subsystem is checked and data is compiled into a standard health packet, 
stored in the smartphone’s SD card and transmitted over the beacon radio at a regular interval of 30 
seconds. The last 10 health packets are stored in the SD card. After every 10 packets sent, the 
beacon radio is rebooted. This phase happens during the first 24 hours of the mission. The mission 
time is kept in the phone throughout the mission so that a system reboot during this phase does not 
reset the 24 hour countdown A health packet consists of: Satellite_ID, restart counter, reboot 
counter, Phase 1 count, Phase 2 count, time, battery voltage, temp 1, temp 2, accel X, accle Y, accel 
Z, MagX, Mag Y, Mag Z, text “hello from he avcs” 

Phase 2 

This phase starts once a full system health check has been performed. During this phase, image 
packets and health packets are sent to Earth through the beacon radio. A health packet is sent once 
for every 9 image packets downlink. 

This phase can be divided in 3 sub-phases 

• Health Data Measurements: Health data is measured and the 10 most recent samples are 
stored in the SD card. 

• Health Data Downlink: Once 9 packets have been sent through the beacon containing image 
information, the 10 th one is reserved for a health packet. 

• Image Sequence: One picture is taken every minute until 100 pictures are taken and stored 
to the SD card. Pictures are then analyzed and the top image is selected. This image is 
packetized and compiled into standard image packets. These image packets are transmitted 
over the beacon radio coupled with health packets in the ratio explained above. 

Safe Mode 

If the watchdog detects that the phone is not sending any data to the radio for a certain period of 
time, the spacecraft functionality is reduced to the bare minimum. In this condition, the spacecraft 
only transmits health data containing the last 10 sensor data values stored in the SD card prior to 
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failure. This mode lasts for 90 minutes. After this period, the spacecraft resumes its normal 
operations. A safe mode packet consists of: Satellite ID, last 10 voltage values , last 10 temperature 
sensor 1 values , last 10 temperature sensor 2 values , text “SAFEMODE” 

4.6 Testing 

In order to validate the design, PhoneSat 1.0 went through an extensive series of testing. A radio 
range test was conducted over 37km straight line-of-sight distance in order to validate the 
communications link. This showed that the link was strong enough to receive data from the satellite 
if it were placed in a 500km altitude orbit. Next, the spacecraft passed a week-long test to prove the 
robustness of the system and the stability of the software. To prove the flight readiness of the 
system and the team, PhoneSat 1.0 was lifted in a balloon up to 30km altitude while doing the 
operations described in the previous section. This test served to expose PhoneSat 1.0 to temperature 
extremes (during the test, temperatures below -5C were recorded) and to test the communications 
system in a more dynamic manner. The analysis of the test results showed that the system 
performed as expected. 

Subsequently, PhoneSat 1.0 underwent environmental qualification and acceptance testing at NASA 
ARC. PhoneSat 1.0 was first placed into a bell jar Thermal Vacuum chamber and successfully 
underwent days of Day in the Life test to simulate on orbit operations. To help qualify the satellite 
for severe and harsh launch environment, the satellite then underwent Random Vibration and 
Mechanical Shock testing to launch provider-prescribed levels. After satisfying these requirements, 
the satellite was placed into the Bell Jar again for Thermal Vacuum Bakeout for 60°C over 6 hours 
in order to outgas all parts. 

After successfully qualifying PhoneSat 1.0, multiple units were assembled, baked out in a vacuum 
chamber and thermally cycled in an oven between -5°C and 45°C for approximately 12 hours. 
Then, two PhoneSat 1.0s were selected to be combined with a PhoneSat 2.0 beta in a flight-like 
ISIPOD for acceptance vibration testing. 
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5 PHONESAT 2.0 


5.1 Description 

PhoneSat 2.0 is an extension of PhoneSat 1.0; building on and supplementing it’s capabilities to 
form a low cost satellite bus. Bus subsystems for PhoneSat 2.0 were designed to include: command 
& data handling, electric and power system, two-way communications, and attitude control and 
determination system. The agile space development methodologies were continued in an effort to 
minimize project cost and focus on the technology whilst eliminating un-necessary overhead. The 
PhoneSat 2 series of satellites have been built as flight units in multiple instantiations. PhoneSat 2.0 
Beta was baselined with the available capabilities of C&DH, EPS and minimal ACS in order to 
leverage a delayed launch of the PhoneSat 1.0 manifest. PhoneSat 2.4 was baselined for the ELaNa 
4 flight manifested on ORS-3. PhoneSat 2.5 was baselined for the ELaNa 5 manifest on SpaceX 
CRS-3. Flight data from the PhoneSat 2.0 Beta baseline is presented later in this report, whilst 
PhoneSat 2.4 data will be presented in a future report and PhoneSat 2.5 is currently sitting on the 
launch pad. The following section describes PhoneSat 2. Error! Reference source not found, 
depcits that PhoneSat 2.5 spacecraft - part of the PhoneSat 2.0 series of Spacecraft. 



Figure 5. PhoneSat 2.5 


5.2 Mission objectives 

Demonstrate bus functionality for parts cost of less than $10k. Defined objectives were (1) 
command and data handling on a smartphone (2) power generation (3) rate control of the satellite. 
In addition, a focus was given to monitoring longevity of the smartphone and peripheral 
microprocessors in the LEO radiation environment. 


5.3 Hardware architecture 

PhoneSat 2.0 is more complex from a hardware point of view than PhoneSat 1.0; focusing on 
providing more subsystems for bus functionality whilst maintaining the 1U form factor. The 
hardware architecture supports; a new Electric Power System (EPS) architecture, second radio for 
two-way communication, an attitude determination and control system (ADCS), a distributed 
network of sensors throughout the spacecraft and a new smartphone model as well as data interface 
architecture. 

PhoneSat 2.0 has a new electric power system (EPS) architecture, a second radio that provides two- 
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way communications, an attitude determination and control system (ADCS), a distributed network 
of sensors throughout the spacecraft and a new smartphone model as well as data interface 
architecture. 

In terms of the EPS, the system uses high efficiency multi-junction TASC solar cells that populate 
all six external faces of the spacecraft. These solar cells are used to charge 4 Li-Ion batteries similar 
to the ones used in PhoneSat 1.0, the battery arrangement is two batteries in series and two in 
parallel that provide a 7.4 nominal bus voltage. The unregulated power from the batteries is down 
converted for each subsystem as needed. PhoneSat 2.0 retains the ATmega 328 microcontroler that 
PhoneSat 1.0 uses as a watchdog; with the added functionality power management. 

For the communications subsystem, PhoneSat 2.0 keeps the same Stensat beacon radio and the tape 
measure antenna as PhoneSat 1.0. Additionally, the Microhard MHX-2420 radio operateing on 
2.4GHz ISM band at 1W output power, is used for two-way communications. A patch antenna 
designed by Astronautical Development, LLC is used for this radio. 

The attitude determination utilizes the Nexus S smartphone built-in magnetometer and gyro as well 
as current sensors for the solar panel as a coarse sun sensor. For attitude control, PhoneSat 2.0 has 
magnetic coils on all six faces of the CubeSat and three brushless DC motors that are used as 
reactions wheels to orient the spacecraft. 

PhoneSat has a set of sensors across the satellite that measure current and temperature as well as 
monitor the state of the battery. This data is used primarily for sate of health monitoring. 

The data architecture of PhoneSat 2.0 is centred around the serial converted USB port of the 
smartphone and a serial router. This architecture enables multiple devices to talk to each other as 
well as the smartphone.. Figure 6 and Figure 7 show a power and data diagram respectively of the 
PhoneSat 2.0 bus. 



Figure 6: PhoneSat 2.0 power distribution architecture 
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Figure 7: PhoneSat 2.0 data distribution architecture 


5.4 Software architecure 

In following the expansion from a single smartphone in Space for PhoneSat 1.0 to a capable bus for 
PhoneSat 2.0, the Software Architecture expanded and made use of a more modular design. The 
software is organized in different layers that interface with the android framework. Figure 8 shows a 
diagram of the software 

architecture, followed by a detailed description of each section. 
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Figure 8: PhoneSat 2.0 software architecture 

phonesat.app : this software package contains the applicative. It handles the execution of the 
concept of operations. 

• Stabilize: this activity is run after the deployment of the spacecraft to stabilize it. This is 
performed by using magnetic coils. 

• MagneticAlignment: this activity is a variant of Stabilize. It also uses the magnetic coils to 
stabilize the spacecraft, but also apply a constant magnetic field in order to align one 


The 4S Symposium 2014 -A. Guillen Salas 


11 





specific axis of the spacecraft to the magnetic field of the Earth. This activity is run prior to 
a ground communication. 

• PointingDemo: this activity is controlling the reaction wheels of the spacecraft to point to a 
designated target. It is either used to take picture of the moon or to align the S-band antenna 
to the ground station. 

• AlignmentDownlink: this activity is running the same ADCS algorithm than 
MagneticAlignment, plus turns the S-band radio ON to establish a ground to space 
communication. The magnetic alignment allows a better communication link by aligning the 
S-band antenna. 

phonesat. service: this package contains the code needed to handle the Android execution flow of 

the App. 

• PhoneSatService: this is the generic Android service managing the flight application. It 
handles the initialization of the system. 

• PhoneSatReceiver: this is a generic Android broadcast receiver. It receives various phone 
internal events from Android and passes them to the flight application. 

phonesat. adcs: this package contains the ADCS algorithms. 

• AdcsManager: this class is running the ADCS algorithms in a dedicated low-latency thread. 
It listens for activities (phonesat.app) to determine which algorithms to use, executes these 
algorithms and controls the magnetic coils and reaction wheels. 

phonesat. executive: this package contains the code to schedule and execute the mission activities. 

• ExecutiveThread: this class holds a single thread of execution where the mission activities 
are posted. This is a simple queue (first in - first out) of pending activities. 

• Scheduler: the activities to execute are written in a text file on the phone file system. This 
file contains the start time and the name of the activities to execute. This file is written by 
the ground station every time a link is established. The Scheduler class is responsible to read 
this file and push the pending activities to the ExecutiveThread. 

phonesat.packet : this package contains the code to encode beacon packets. 

• PacketEncoder: this class encodes the beacon packets. 

phonesat.hardware: this package contains the device drivers for the PhoneSat hardware. 

• Watchdog: this class is the driver for the Watchdog device. 

• Sensorlnterface: this class is the driver for the sensor interface. It receives the sensor data 
which is external to the phone, like temperature sensors and current sensors. 

• Acs: this class is the driver for the ACS device. The ACS device controls the magnetic coils 
and the reaction wheels. 

• Stensat: this class is the driver for the Stensat beacon radio. 

• Microhard: this class is the driver for the Microhard radio. 

5.5 Concept of operation 

Because PhoneSat 2.0 does not have an onboard GPS, the mission schedule is determined on the 

ground and uploaded to the spacecraft. The possible activities that can be programmed are 

described in the software architecture (package phonesat.app). 
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When no schedule has been uploaded yet or when the current schedule has been fully executed, the 
spacecraft enters a ground listening mode described below. 

Initialization - Deployment sequence 

Once PhoneSat 2.0 is deployed from the launch vehicle, the watchdog turns on and starts a counter. 
After 50 minutes, the smartphone starts the Stabilize activity for 5 hours in order to detumble the 
spacecraft. Once this activity is completed, it starts the MagneticAlignment activity for 1 hour. 

Ground listening mode 

When in this mode, the smartphone will aligns the spacecraft to the Earth’s magnetic field and 
listen for ground commands over the Michrohard radio. 

The chances of establishing a ground link depends on the duration to charge the batteries; the 
shortest the better. 

Scheduler mode 

When the phone has a valid time and a schedule file with one or more pending activities to execute, 
it will wake-up to execute these activities. The phone will be sleeping the rest of the time, keeping 
the maximum battery power for the scheduled activities. 

Sleeping mode 

In this mode the phone is off, the only microcontroller powered on is the watchdog which transmits 
a health packet every 2.5 minutes. 

5.6 Testing 

Similar to PhoneSat 1.0, all instantations of PhoneSat 2.0 (PhoneSat 2.0p, PhoneSat 2.4, and 
PhoneSat 2.5) were extensively tested. PhoneSat 2.0P, the trailblazer for PhoneSat 2.4 and 
PhoneSat 2.5, tested successfully in two suborbital flights, UpAero’s SL6 launch in April 2012 and 
Garvey Spacecraft Corporation’s (GSC) P-19 rocket in December, 2012. The Up Aero launch 
exposed the satellite hardware to extreme environments up to 117 km, providing confidence that the 
satellite hardware could survive a harsh and severe orbital launch. The GSC launch verified the on 
board radios’ ability to close the link to a ground station. 

Following the successful completion of these suborbital flights, PhoneSat 2.0P underwent 
qualification testing. First, the satellite was baked out at 50°C for 12 hours in the bell jar. Then the 
satellite was power tested under vacuum between 12°C and -20°C for more than 18 hours. Finally, 
the satellite was performing on orbit operations while thermally cycled under vacuum to between on 
orbit predicted temperatures. PhoneSat 2.0P then successfully passed the Mechanical Shock test at 
launch provider-prescribed levels. The satellite was then tested at qualification Random Vibration 
levels. 

After this unit was qualified, PhoneSat 2.4 and PhoneSat 2.5 were subjected to similar tests with 
levels adjusted to meet each launch provider’s requirements. 


6 IN-FLIGHT TEST RESULTS FROM THE ANT ARES MAIDEN FLIGHT 
6.1 Payloads 

The first PhoneSat on orbit was delivered by the Antares maiden flight on April 21, 2013. On board 
this launch system there were three PhoneSat units. Two copies of the PhoneSat 1.0 and one beta 
release of the PhoneSat 2.0 with preliminary baselined capabilities. The PhoneSats were named 
“Alexander”, “Graham” and “Bell” in honor of Alexander Graham Bell the inventor of the first 
practical phone. Graham and Bell were two full PhoneSat 1.0 vesions, Alexander was the PhoneSat 
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2.0 Beta which included the power and data architecture of PhoneSat 2.0. All three spacecraft 
achieved more than 100% of the mission objectives. Figure 9 shows the spacecraft before 
integration in the dispenser. 



Figure 9. From left to right: PhoneSat 2.0 beta (Alexander), PhoneSat 1.0 (Graham) and PhoneSat 

1.0 (Bell) 


6.2 Mission overview 

The three PhoneSats were deployed into a 260km x 240km altitude orbit at 51.6 degrees inclination. 
Since the satellites were deployed in such a low orbit - their orbital life time was very short, 
approximately 5 days - the radio amateur community support became a key element in order to 
receive a greater number of packets from the satellite. A website was setup where the radio 
amateurs could store and share packets received from the satellites. The response from the radio 
amateur community was great with more than 100 amateur operators consistently tracking PhoneSat 
all around the world. Figure 10 gives an idea of the distribution of radio amateurs that registered on 
this website (www.phonesat.org). 



Figure 10. Radio amateurs registered on www.phonesat.org 

6.3 In-flight results 

PhoneSat 1.0 health data 

Graham and Bell collected battery voltage data, accelerometer and magnetometer data from the 
sensors built into the smartphone and temperature from two external sensors placed in different 
locations of the spacecraft. Figure 11 shows the battery voltage over time for both spacecraft. As it 
can be observed, both PhoneSat 1.0 units depleted their batteries at a similar rate. 
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Figure 11. Battery voltage evolution over time. ■ represents data from Graham, represents data 

from Bell. 


Figure 12 and Figure 13 show the accelerometer and magnetometer data from Graham. Similar data 
was received from Bell, this data is no shown in this paper to keep it more concise. This 
acceleration is a product of noise, no flight calibration and the sensor being located away from the 
center of mass. The magnetometer data shows a value of a magnetic field module is time variant 
and greater than the field for this orbit due to parasitic magnetic field in the satellite. 



Figure 12. Accelerometer data from Graham. ■ : acceleration X axis, : acceleration Y axis, : 

acceleration Z axis, : acceleration module. 
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Figure 13. Magnetometer data from Graham. ■ : magnetic field X axis, : magnetic field Y axis, 

: magnetic field Z axis, : magnetic field module. 

Finally, Figure 14 shows the temperature recorded by the sensors for both spacecrafts, as it can be 
seen, it ranged from - IOC to +30C approximately. 



Figure 14. Temperature data from Graham and Bell. 1 : temperature sensor 1 - Graham, : 
temperature sensor 2 - Graham, : temperature sensor 1 - Bell, : temperature sensor 2 - Bell. 

Figure 15 shows a transition from eclipse to sun light and how the satellite increasingly warms up 
from -3C to 14C. 
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Figure 15. Temperature variation on the PhoneSat 1.0 while transitioning from eclipse to sun light. . 
■ : temperature sensor 1 - Graham, « : temperature sensor 2 - Graham. The orange line represents 
the time under sunlight and the black line the time in eclipse. 

In terms of the phone survivalability to the space environment, one phone reboot was observed in 
Grahan and four in Bell during the five day mission. In terms of radio signal strength, the packets 
were decoded consistently from both spacecraft. 

PhoneSat 1.0 imaging 

On the second day of the mission, the spacecraft started downloading the pictures that had been 
taken. Over the course of the remaining days of the mission, the picture packets were assembled as 
a jigsaw puzzle. The image was stored in low, medium and high resolution, each packetized into 
lengths appropriate for the beacon transmitter. Priority was assigned to the low resolution packets in 
order to ensure a complete image to some resolution was received. By the end of the orbital 
lifetime, high resolution packets had begun to be transmitted. Figure 16 shows the images taken of 
Earth by each smartphone camera from Space. 
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Figure 16. PhoneSat 1.0 pictures. Left: Bell pictures. Right: Graham pictures. The top pictures 
correspond to the second day of the mission, the middle pictures are from the third day of the 
mission and the bottom ones are the last ones obtained. 

Table 1 shows the number and percentage of each picture packet type that were received. 

Table 1. Picture packets received for each satellite 



Graham 

Bell 

Background image 

1 

100% 

1 

100% 

Medium resolution image 

53 

83% 

40 

63% 

High resolution image 

109 

43% 

61 

24% 


PhoneSat 2. 0 beta data 

Phone 2.0 beta collected smartphone sensor data including compass, gyro and accelerometer. In 
addition, subsystem current consumption as well as solar panel current generation were measured. 
The satellite also recorded temperature on eleven different locations of the spacecraft. The 
temperatures recorded ranged between -1C and 27C for the interior of the spacecraft and -20C and 
+40C for the exterior. Counters on the smartphone and arduino’s all showed zero reboots. The 
obtained gyroscope data from the smartphone is shown in Figure 17 below. A waiver was obtained 
with the LSP to allow no bum-wire for the deployable tape measure antenna. Subsequently, the 
antenna deployed against the ejection module, creating a high initial spin rate of the spacecraft. 
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Figure 17 - PhoneSat 2.0 Beta Smartphone Gyroscope 
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7 PHONESAT CONTINUOUS EFFORT 

PhoneSat is an iterative effort that has continued post flight of the Antares. Two PhoneSat 2.0 
version of the satellite were delivered for the ORS-3 Minatour 1 and SpaceX CRS-3 flight. The 
satellite (PhoneSat 2.4) manifested on ORS-3 launched in November 2013 and successfully 
accomplish the mission. Additionally, two PhoneSat 2.5 ’s will launch on the SpaceX CRS-3; the 
second as the bus for KickSat. 

EDSN, a swarm of 8 satellites designed a NASA Ames Research Center, is an extension of the 
PhoneSat 2.0 bus designed for space communication networks. The EDSN mission is schedule to 
launch at the end of 2014. The PhoneSat team is currently working on new concepts for PhoneSat 
3.0 and beyond. 

8 CONCLUSION AND ACKNOWLEDGEMENTS 

The PhoneSat Project has successfully demonstrated the use of consumer technology, namely the 
smartphone to supplement traditional space hardware to drastically reduce cost. In addition, agile 
development has been successfully employed in order to maximise technological advancement over 
time. With satellite bus functionality now possible for consumer technology prices, a substantial 
number of missions for science, education technology and commercial applications are now 
economically viable. A large thank you to the innovative cO-PIs that formed the foundation for this 
project: Chris Boshuizen and Will Marshall, in addition to the team that gave this projects its initial 
success. 
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